-
Notifications
You must be signed in to change notification settings - Fork 38
Add support for fixed total magnetization and optional features #344
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for fixed total magnetization and optional features #344
Conversation
This PR adds support to run fixed spin moment calculations, i.e., enabling the user to specify the total magnetization of the cell that is kepy during the calculation. Moreover, since this is a new feature that is not supported by all the plugins in the beginning (or maybe in general), this PR also introduces the concept of additional optional features in the common workflows. Once the plugin developers add support for that feature, it will be enabled and is ready to use.
|
First an example to test the previous EOS workflow with fixed magnetization: %load_ext aiida
%aiida
from aiida.orm import List, Dict
from aiida.engine import submit, run
from aiida_common_workflows.plugins import WorkflowFactory
from aiida_common_workflows.common import ElectronicType, RelaxType, SpinType
cls = WorkflowFactory('common_workflows.eos')
engines = {
'relax': {
'code': 'qe-7.3-gf-pw@thor',
'options': {
'resources': {
'num_machines': 1,
'num_mpiprocs_per_machine': 48,
},
'queue_name': 'short',
'max_wallclock_seconds': int(900),}
}
}
structure =
inputs = {
'structure': structure,
'scale_count': Int(3),
'generator_inputs': { # code-agnostic inputs for the relaxation
'engines': engines,
'protocol': 'fast',
'relax_type': RelaxType.NONE,
'spin_type': SpinType.COLLINEAR,
'fixed_total_cell_magnetization': 2.0,
},
'sub_process_class': 'common_workflows.relax.quantum_espresso', # the relaxation workflow to use
}
run(cls, **inputs)and for the energy vs. magnetization: energy_magnetization = WorkflowFactory('common_workflows.em')
inputs = {
'structure': structure,
'fixed_total_magnetizations': [0.5, 0.53, 0.56, 0.59, 0.62, 0.65, 0.68, 0.71],
'generator_inputs': { # code-agnostic inputs for the relaxation
'engines': engines,
'protocol': 'fast',
'relax_type': RelaxType.NONE,
'spin_type': SpinType.COLLINEAR,
},
'sub_process_class': 'common_workflows.relax.quantum_espresso', # the relaxation workflow to use
}
wc = submit(energy_magnetization, **inputs)and finally, to test the optional feature logic: RelaxWorkChain = WorkflowFactory('common_workflows.relax.quantum_espresso')
print(RelaxWorkChain.get_input_generator().get_optional_features())
print(RelaxWorkChain.get_input_generator().get_supported_optional_features())
RelaxWorkChain = WorkflowFactory('common_workflows.relax.siesta')
print(RelaxWorkChain.get_input_generator().get_optional_features())
print(RelaxWorkChain.get_input_generator().get_supported_optional_features())
# Outputs:
# {<OptionalRelaxFeatures.FIXED_MAGNETIZATION: 'fixed_total_cell_magnetization'>}
# {<OptionalRelaxFeatures.FIXED_MAGNETIZATION: 'fixed_total_cell_magnetization'>}
# {<OptionalRelaxFeatures.FIXED_MAGNETIZATION: 'fixed_total_cell_magnetization'>}
# set() |
|
Thanks @t-reents! I haven't looked into the common workflows in quite some time, so would have to get an overview of the codebase again before being able to do a proper review. Right now, I don't think I can add another project to my plate. So feel free to go ahead without me signing off on things with @giovannipizzi! Maybe once I'm back in Switzerland I can dedicate some proper time to this package again, it definitely has a lot of potential. :) |
bosonie
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @t-reents, and nice t meet you! After a chat with @giovannipizzi, we agreed I could have a look at this PR. Hopefully it speeds up the work on your side and helps me to remember a bit about this nice project. I left you some comments! Let me know if you agree.
…an effective magnetic field based on the difference between the fermi energy of the spin-up and spin-down channel
|
Hi @bosonie ! Indeed, nice to meet you and thanks a lot for having a look at this PR! As you could already see/read, I agreed with all your comments.
Thanks again for the helpful review, it speeds up our work! As outlined above, I incorporated the changes and added (some small) additional ones. If you find the time, your final feedback would be greatly appreciated, so that we can get this merged. |
bosonie
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @t-reents. All good and I approve the PR. However I kindly ask you to open two new issues, so we do not forget about two related points:
- The documentation of the new em workchain.
- The implementation of the fermi energy output and, when applicable, the
fixed_total_cell_magnetizationinput for all the other plugins.
Bye!
|
Thanks a lot @bosonie ! Yes, those were the missing/future aspects I was also thinking about. |
Explanation in the commit message:
This PR adds support to run fixed spin moment calculations, i.e., enabling the user to specify the total magnetization of the cell that is kept during the calculation.
Moreover, since this is a new feature that is not supported by all the plugins in the beginning (or maybe in general), this PR also introduces the concept of additional optional features in the common workflows. Once the plugin developers add support for that feature, it will be enabled and is ready to use.
In addition to just supporting fixed total magnetization in the relaxations, we also add a workflow to calculate the energy as a function of the (fixed) magnetization. This is very similar to the previous Equation of state.
The idea of the optional features is that a common workflow can define a set of optional features that are in principle supported, e.g.,
_optional_featuresin theCommonRelaxInputGenerator, and the specific implementation has to define and override which of those features are actually supported, see_supported_optional_featuresinQuantumEspressoCommonRelaxInputGeneratorand in the test below.@mbercx pinging you here for a review as I remember that you were also again interested in the common workflows. Please note that this is a feature that we need for our current project for the AE verification. Hence, we were initially thinking to just do it in a very hacky way. This is just to say that I tried to find a general solution here that can be expanded to other workflows in the future, while still keeping it practical for our current project.
Let me know if you have any major concerns/comments. Otherwise, @giovannipizzi and me would be keen on proceeding 😄